Communications networks have an infrastructure including network nodes, and interconnecting links. Typically a variety of network elements are employed, each of which provides a specialized function. Communications network nodes may include more than one network element. Data content is conveyed over the interconnecting links in accordance with multiple transport protocols, each of which addresses particular service needs.
FIG. 1 is a schematic diagram showing interconnected network elements implementing connected communications networks.
Network nodes 102, 102-A, 102-B, 106 are physically interconnected via physical links 104 in communications networks 100. Communications networks 100 may be bridged via bridge network nodes 106 to enable data content exchange therebetween. Connected communications networks 100 can be grouped defining areas of focus and influence for the purposes of network management, known as network partitions 108.
All data network equipment is subject to design choices which are bound to differ from vendor to vendor. For example, as shown schematically in FIG. 1, an equipment vendor may chose to implement an integral network node device 102-B having a switching processor and a group of ports 110. Another equipment vendor may chose a customizable implementation of a network node 102-A including: a switching fabric, an equipment rack divided into shelves, each shelf 120 having slot connectors 122 for connection with interface cards, each interface card 124 having at least one port 110.
Network management is concerned, at least in part, with monitoring managed communications network equipment to ensure adherence to a defined communications network state. Configuration management is concerned with the definition of the communications network state which includes configuring operational parameters associated with field-installed managed communications network equipment to operate in a desired fashion.
In the prior art an operator would manually configure each managed network element (equipment and/or entity). The operator would employ a vendor and network equipment specific Element Management System (EMS) to access a corresponding specific piece of field-installed network equipment, and use manual command entry to effect each desired change.
Performing such manual configurations on a large number of communications network nodes and the associated equipment is time consuming, costly, and error-prone. One of the biggest drawbacks to using the time consuming manual methods is that configuration management is to be performed within specific service time windows so as to minimally impact service provisioning. Performing large scale manual configuration management has and will continue to be a bottleneck in maintaining a high level of managed communications network reliability, availability and serviceability (RAS) as trends in the field of communications show an increasing demand for services, provided over an expanding and increasingly complex communications network infrastructure.
An improvement to the manual configuration approach includes custom script writing which enables performing specific configurations via a batch of commands in an EMS configuration management context. As a simple bulk configuration management example, a custom script may be used in configuring the size of an input buffer for each port 110 of a single vendor specific communications network node type. Using such configuration scripts reduces somewhat the time required to configure all ports 110 of a network node 102-B as the density of ports 110 per network node 102-B increases.
However, if only a subset of ports 110 needs to be configured for a network-node 102(A/B), the operator, besides using the EMS to access each network node 102(A/B), must dedicate time to manually select the ports 110 to be configured. As the number of network nodes 102 to be configured increases and the density of ports 110 per network node 102 increases to fill service demand, the time needed to select the network nodes 102 and the ports 110 also increases. Further custom command scripts must be defined for each vendor communications network equipment type as the configuration command sets may vary. Certain advancements have been proposed and implemented including: the use of the Simple Network Management Protocol (SNMP) to reduce reliance on multi-vendor EMS solutions. However the SNMP solution: is not suited for certain applications leading to an increased configuration management overhead, not widely adopted by all vendors, and/or is not implemented on all vendor communications network equipment types.
Custom command scripts are more efficient than performing the operations manually, however errors can still occur. As the scripts can be executed faster than manual command input, in an attempt to comply with the stringent time requirements imposed by management time windows, inadvertent errors in command scripts take effect, in affecting the operation of the configured equipment, at corresponding fast rates. Typical command script execution is performed without regard to errors.
Even though employing configuration scripts represents an improvement over strictly manual configuration methods, the configuration management is still limited to the EMS configuration context in which each communications network element needs to be identified and accessed, using a custom specific EMS for each communications network element.
In a Network Management System (NMS) configuration context, instances of managed entities including: network nodes 102/106 (aggregators switches, routers, bridges, gateways, etc.), interface cards 124, ports 110, paths 112, links 104, etc. hold operational parameter specifications for corresponding managed field-installed network equipment. The managed entity instances form an interconnection hierarchy defined by associations between the managed entity instances, the managed entity instances and the associations defining a containment hierarchy.
An exemplary containment hierarchy 200 of managed network entities, shown in FIG. 2, is maintained for network management purposes. Each managed network entity instance in the containment hierarchy 200 corresponds to a field-installed physical managed entity or a defined logical managed entity in the realm of influence. Exemplary physical managed entities include, but are not limited to: physical links 104, physical ports 110, interface cards 124, shelves 120, network nodes 102, routers, bridges 106, gateways, aggregators, etc. Exemplary logical managed entities include, but are not limited to: network partitions 108, link groups 204, logical trunks 206, logical ports 210, paths 112, virtual routers, etc.
As an example, typically link groups 204 are used to provide inverse multiplexing. A link group 204 is typically defined to include a group of physical links 104 used in combination to convey content at the aggregate bandwidth of the group of physical links 104. The group of physical links 104 in the link group 204 connect to a corresponding group of ports 110 associated typically with an interface card 124 providing inverse multiplexing functionality. The corresponding group of physical ports 110 define a logical port 210. In conveying content, a data flow may be routed onto a link group 204, the inverse multiplexing interface card 124 distributing the data flow bandwidth over the individual physical links 104 in the link group 204.
As another example, typically logical trunks 206 are used to provide redundant content transport. Each logical trunk 206 is typically defined to include at least one designated active physical link 104, actively used for conveying content, and at least one designated standby physical link 104, reserved to convey content in the event that the associated active physical link 104 experiences a failure. Typically the physical links 104 in a logical trunk 206 connect to physical ports 110 on different interface cards 124 to provide redundancy. The corresponding group of physical ports 110 define a logical port 210. In conveying content, a data flow may be switched to the logical port 210, the combination of interface cards 124 cooperating to direct content transport over the active physical link 104 or the standby physical link 104 dependent on the operational status of the designated active equipment (physical link 104, corresponding physical port 110, corresponding interface card 124, etc.)
An NMS 230 such as an Alcatel 5620 NMS interacts with the containment hierarchy 200 to provide an operator, typically, with a visual display of the managed communications network state. Further, the NMS 230 is used to interact with the field-installed communications network equipment either directly or indirectly via interaction with managed communication network entity instances in the containment hierarchy 200. Network management information is reported to the NMS 230 and status registers associated with the corresponding managed communications network entity instances in the containment hierarchy 200 are updated accordingly.
Current NMS 230 solutions such as the Alcatel 5620 NMS provide for centralized individual communications network entity configuration in a NMS configuration context without recourse to EMS solutions. There therefore is a need for improved centralized bulk configuration management solutions providing a high level of network reliability, availability, and serviceability (RAS).